這篇文章是 Prograss Bar 網站「不是工程師」系列內，「資料庫正規化」系列文章，以及另一篇欄位共用文章的摘要，以及個人的一些想法。推薦在設計資料表時閱讀，確保資料庫的查詢效能和編輯的方便性。

「資料庫正規化」文章摘要

第一正規化的關鍵：資料表內沒有重複的紀錄，可以透過設定主鍵 (Primary Key, PK) 達成，通常是建立 ID 欄位。

如果能確保資料表裡有唯一的紀錄，就可以明確的查詢到特定紀錄，不用擔心會新增/查詢到重覆資料的問題！

「不是工程師」關聯式資料庫正規化是什麼? 先從第一正規化(1NF)開始吧！(database normalization, Primary Key - PK)

第二正規化的關鍵：將容易重複資料、只和表格部分相關的欄位，拆分成不同表格，建立外來鍵 (Foreign Key)，和其它表格產生關連。

資料表有很多重複欄位時，會導致資料量過大，占用很多儲存空間，並花費很多時間查詢！

「不是工程師」外鍵Foreign key(FK)是什麼？從第二正規化(2NF)去除冗余資料談起吧！(database normalization)

第三正規化的關鍵：如果可以從其它欄位計算或推斷出來，就不要設立一個欄位去紀錄。

紀錄要計算的欄位，就要考慮到編輯資料後，有沒有一同更新的問題，否則會有計算結果不正常的問題。

「不是工程師」可以邏輯推斷出來就不要多加欄位？淺談資料庫第三正規化(3NF)

欄位共用的思考

資料庫正規化以後，如果要修改資料，很容易遇到其它欄位沒有一起更新的問題。

設計時就要問自己，哪些資料要留下歷史紀錄，才不會遇到更新資料後，其它欄位產生落差的問題；或是另外寫 SQL 語法定期 / 觸發一同更新其它欄位的資料。

資料庫設計之共用/不共用欄位 - 《Chris 技術筆記》

效能的影響

有時在設計資料表，可能會考量到多個資料表 Join 的影響，違反第二正規化，將資料放在同一張資料表內；也有可能會因為常常取得計算結果，將結果記錄在資料表內，然而這也違反第三正規化。

對於以上效能的案例，需要在效能和正規化設計的優點間做出取捨。